home *** CD-ROM | disk | FTP | other *** search
- Path: soap.news.pipex.net!pipex!usenet
- From: m.hendry@dial.pipex.com (Mathew Hendry)
- Newsgroups: comp.sys.amiga.misc
- Subject: Re: Speed: 68040 vs. 68060
- Date: Fri, 23 Feb 96 19:03:04
- Organization: Private node.
- Distribution: world
- Message-ID: <19960223.425E10.10CBD@an100.du.pipex.com>
- References: <4foi00$60t@gondor.sdsu.edu> <3125E74D.3390@gih.no>
- NNTP-Posting-Host: an100.du.pipex.com
- X-Newsreader: TIN [AMIGA 1.3 950726BETA PL0]
-
- Lee Huggett (Lee@burst.demon.co.uk) wrote:
- : > Full bullshit. I complied a simple real-world test,
- : > and it was about 2x fast as on my 040/40 Warp Engine,
- : > and about a same on P90.
- :
- : Hey Hey Hey don't start getting fucking nasty...
- :
- : What simple real world test??
- :
- : Mail it to me and I'll give it a try...
-
- Try the BYTEMark tests on Aminet, which contain compiled algorithms designed
- to simulate real world applications. They are scaled to performance - faster
- CPUs are given bigger tasks. The results are benchmarked relative to a Dell
- P90, which was quite humbling for my poor Amiga and its aging 40MHz '030 :(
- (approx. 10% of a P90 for integer routines, BTW. Even slower for FP)
-
- : > SysInfo is crap, that 40MIPS is really wrong. My 040/40
- : > does that.
- :
- : I was mearly stating a fact Sysinfo does give 40 MIPS for an '060
-
- The speed tests used in SysInfo fit completely in a 68040's internal cache,
- and therefore also in the larger cache in the 68060. For this reason, and
- others, they do not provide a reliable estimate of real world performance.
- Cache latency, memory access speeds and other factors must also be taken into
- account. On an '040 or '060 MisInfo can't even attempt to do this. You might
- as well be testing an endless loop which JMPs directly to itself ;)
-
- : and seing as AIBB doesn't recognise the '060 to the point of not working at
- : all, we don't really have a lot to work with.
- :
- : I know the '060 is faster the 040/40 (I would have bought one of those
- : otherwise) but I think it is unlikely that you would get 81 MIPS out of it at
- : a sustained rate
- :
- : > Most of the SAS/C compiled code does not have be specially
- : > 68060 optimized, in a real world situation the 060 is
- : > usually able to run 2 instructions at the same time.
- :
- : If code is optimised for an '060 is has more chance of running 2 or more
- : instructions at once then unoptimised code.
-
- Only when a compiler appears which produces code optimised for the '060 can
- you run such tests. Contriving code in assembly language to take advantage of
- new CPU features provides misleading results unless a current compiler (as
- used in the REAL WORLD) optimises code in the same way. Since SAS has
- apparently abandoned support for SAS C/C++ I don't see this happening anytime
- soon. So, your only real world estimates at the moment should be based on
- code compiled for the 68040.
-
- BTW, as far as I know the current AmigaOS itself doesn't recognise an '060.
- The CPU flags in execbase.h only extend up to the 68040. They also show a
- possible lack of forethought -
-
- /* Processors and Co-processors: */
- #define AFB_68010 0 /* also set for 68020 */
- #define AFB_68020 1 /* also set for 68030 */
- #define AFB_68030 2 /* also set for 68040 */
- #define AFB_68040 3
- #define AFB_68881 4 /* also set for 68882 */
- #define AFB_68882 5
- #define AFB_FPU40 6 /* Set if 68040 FPU */
-
- Surely they should have left a gap after AFB_68040 to allow for new additions
- to the 680x0 line ;)
-
- -- Mat.
-